Updating software in the field typically takes on a few different approaches. One approach requires that the full program is updated at any renewal. While the advantage of this approach is that any part of the program may be changed at any renewal, it bears the disadvantage of requiring a sizable amount of upload data and code.
A second approach of updatability involves relegating functionality to be data driven, so that data files control paths of control-flow. While this approach does allow behaviour to be changed at run-time, it requires decisions to be built into the software up-front and can cause the renewability aspect of the approach to be limited, especially for the purposes of protecting the code from being attacked.
A third approach uses the availability of dynamic or shared library mechanisms for updating a set of components. While useful, this approach has the disadvantage of requiring a dynamic linking phase to resolve relocatable symbols at run-time giving a performance overhead resulting in the approach being typically used sparingly for a handful of components. Furthermore, the granularity of what functionality lies within the dynamic library is fairly rigid with regards to the overall system. Moreover, certain platforms do not support dynamic linking.
Current methods for dynamically updatable software components are coarsely-granular, slow, or limited in the code and data that may be updated. Additionally, some methods require the software to not be running while taking an update. Those methods that can load updates while running suffer from coarse-granularity and an inability to predict a high confidence level when loading an update dynamically. Furthermore, the ability of updating software components for the purposes of renewing the security as a response to a breach, or as a forerunner to any perceived attack is not well supported. The existing methods for updatable software have been driven by functional updates and responses to defects in fielded products.
Security problems in existing updatable software component mechanisms include an attacker's ability to prevent taking new updates and rolling back to previous updates. Furthermore, the attacker has the ability to gain a lot of information by looking at differences in software component updates. The differential attack can be mounted between software component updates and between different user installations.